CPANEL-53195: External requests trigger HTTP 500 via cPanel 404 safelock failure

Zoltan Egri | 1b.hu

• September 01, 2026 12:07

We recently investigated CPANEL-53195 on a production server running cPanel 136.0.38 and found some additional behavior that may be useful to others.

Distributed external scanners were repeatedly requesting:

/unprotected/json-minified.js.map

The file does not exist, and each request entered the cPanel 404 handling path, resulting in:

webmaild.lock / cpaneld.lock – Permission denied

followed by an HTTP 500 response.

cPanel Technical Support escalated our case and reproduced the HTTP 500 behavior themselves. They confirmed that it is related to CPANEL-53195 and added the HTTP 500 behavior to the developer case.

In our environment this also caused production monitoring alerts:

cPanel web storage/session/backend errors is CRITICAL

As a temporary mitigation, we added a ModSecurity rule that intercepts this specific URI before it reaches cpsrvd. The request then returns HTTP 404 instead of HTTP 500, and the safelock error is no longer triggered.

cPanel Support explained that the underlying issue originates from a previous security-related change and that a permanent resolution requires changes to the lock-file generation code.

I am posting this separately because the externally-triggerable HTTP 500 behavior and temporary mitigation may help other administrators encountering CPANEL-53195.

Zoltan Egri
1b.hu

• 

  cPRex Jurassic Moderator

  • September 01, 2026 13:35

  Thanks for sharing this!

  0
• 

  mtindor

  • September 01, 2026 13:48

  Where these all seen in /usr/local/cpanel/logs/acess_log ?

  /unprotected/json-minified.js.map

  webmaild.lock / cpaneld.lock – Permission denied

  cPanel web storage/session/backend errors is CRITICAL

  I ask because I'm only seeing the first one in /usr/local/cpanel/logs/access_log

  0
• 

  Zoltan Egri | 1b.hu

  • September 01, 2026 20:38

  Thanks!

  Quick update: still reproducible on 136.0 build 38 — we upgraded from build 37 specifically to check, and the same webmaild.lock Permission denied error came back shortly after, followed by the 500.

  Worth noting the trigger is an unauthenticated external request for a missing static file, coming from distributed scanners. Any internet-facing cPanel server will see this traffic.

  Is there a target version for the fix, or is CPANEL-53195 still under investigation? And is a request-level block (we used a targeted ModSecurity rule) the recommended interim mitigation?

  Full write-up with logs and the workaround: https://1b.hu/blog/cpanel-hiba-okozta-a-rejtelyes-500-as-szerverhibakat

  0
• 

  cPRex Jurassic Moderator

  • September 01, 2026 22:47

  Yes - the request-level block is still the best plan at this time.

  No - I don't have a specific build targeted for this fix just yet.  I did add your blog notes to the case for the developers to review.

  Once I hear something on my end I'll be sure to post!

  0
• 

  Zoltan Egri | 1b.hu

  • September 02, 2026 21:13

  Update: cPanel Technical Support confirmed that they had not seen any previous reports covering the HTTP 500 aspect of this issue, so our documented case helped expand the scope of CPANEL-53195. Our technical findings and feedback on the operational impact have been forwarded to the cPanel development team for further review. There is currently no estimate for when a permanent fix will be available.

  The targeted ModSecurity rule remains in place and continues to prevent the affected request from reaching the failure path.

  Full English write-up, including the request chain, production findings and the exact mitigation rule:
  https://1b.hu/en/blog/cpanel-53195-external-requests-trigger-http-500-via-404-safelock-failure

  0
• 

  Zoltan Egri | 1b.hu

  • September 03, 2026 05:29

  Good question — they come from three different sources, not all from access_log.

  1. /unprotected/json-minified.js.map — yes, this is visible in /usr/local/cpanel/logs/access_log. This is the only one of the three that appears there, which matches what you're seeing.

  2. webmaild.lock / cpaneld.lock — Permission denied — these appear in /usr/local/cpanel/logs/error_log, not the access log. Look for a message similar to:

  safelock: Failed to create a lockfile '/var/cpanel/cache/404/webmaild.lock' Permission denied

  followed by a FileCreateError exception and stack trace. Correlating the timestamp with the corresponding access_log request is what tied the two together for us.

  3. cPanel web storage / session / backend CRITICAL — this is not a cPanel log entry at all. It came from our external Nagios monitoring of the cPanel service endpoints. The alert fired at the same time as the error_log entries, which is what made the operational impact visible rather than leaving it as an isolated log error.

  So if you're only checking access_log, the connection is easy to miss. The request is visible there, the actual safelock failure is in error_log, and HTTP 500 is the response returned to the client.

  If you're seeing the same entries in access_log, it would be worth checking /usr/local/cpanel/logs/error_log around the same timestamps for the safelock / Permission denied messages. An independent confirmation of the same request → safelock failure → HTTP 500 sequence would be very useful for the case.

  1
• 

  Fahad Marketer

  • September 03, 2026 07:34

  Thanks for sharing this detailed investigation, Zoltan. The externally triggered HTTP 500 behavior is particularly useful to know, especially since it can generate misleading production alerts.

  The ModSecurity mitigation for the affected URI sounds like a practical temporary workaround until cPanel releases a permanent fix for CPANEL-53195. Hopefully the changes to the lock-file generation code will address both the permission errors and the resulting HTTP 500 responses.

  Appreciate you documenting the findings and workaround for the community.

  0

Please sign in to leave a comment.